Add support for filename, content-type and headers when uploading files #129
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The requests library has support for passing additional information, such as the intended filename on upload, the content-type and additional headers, by passing a tuple with 2, 3 or 4 elements instead of just a file object. See "POST a Multipart-Encoded File" in requests documentation for details: https://requests.readthedocs.io/en/latest/user/quickstart/#post-a-multipart-encoded-file Extend aptly_api files API to also be able to take similar tuples when uploading files to Aptly. One useful use case is to pass a proper package filename, in cases where packages are generated simply as <name>.deb by upstream projects (usually via non native Debian build systems) but should more properly be stored as <name>_<epoch>:<version>_<arch>.deb. Renaming files locally is a possibility, but potentially runs into permission issues. Being able to specify the filename to the API solves this in a more elegant way, without having to modify the local filesystem. The package information can be easily derived using debian.debfile.DebFile() to inspect a package file, in specific gencontrol() returns the fields of the control file which can be used to derive the expected filename. Tested locally by uploading files to aptly using the modified API. Also added a test (even though it mostly relies on mocks.) Confirmed mypy is happy with all the type annotation.
|
@jdelic would you kindly take a look? Thanks! |
|
Hi @jdelic would you be able to take a look? I'd love to have this feature added to aptly-api-client, thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The requests library has support for passing additional information, such as the intended filename on upload, the content-type and additional headers, by passing a tuple with 2, 3 or 4 elements instead of just a file object.
See "POST a Multipart-Encoded File" in the requests documentation for more details:
https://requests.readthedocs.io/en/latest/user/quickstart/#post-a-multipart-encoded-file
Extend aptly_api files API to also be able to take similar tuples when uploading files to Aptly.
One useful use case is to pass a proper package filename, in cases where packages are generated simply as
<name>.debby upstream projects (usually via non native Debian build systems) but should more properly be stored as<name>_<epoch>:<version>_<arch>.deb. Renaming files locally is a possibility, but potentially runs into permission issues. Being able to specify the filename to the API solves this in a more elegant way, without having to modify the local filesystem. The package information can be easily derived usingdebian.debfile.DebFile()to inspect a package file, in specificgencontrol()returns the fields of the control file which can be used to derive the expected filename.Tested locally by uploading files to aptly using the modified API. Also added a test (even though it mostly relies on mocks.) Confirmed mypy is happy with all the type annotation.